Mission command timeout #3495
Mission command timeout #3495
Conversation
en/advanced/gimbal_control.md
Outdated
| ## Gimbal Control in Missions | ||
|
|
||
| [Gimbal Manager commands](https://mavlink.io/en/services/gimbal_v2.html#gimbal-manager-messages) may be used in missions if supported by the vehicle type. | ||
| For example [MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW) is supported in [multicopter mission mode](../flight_modes_mc/mission.md). | ||
|
|
||
| In theory you can address commands to a particular gimbal, specifying its component id using the "Gimbal device id" parameter. | ||
| However at time of writing (December 2024) this is [not supported](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/gimbal/input_mavlink.cpp#L889): all commands are sent to the gimbal with id [MAV_COMP_ID_GIMBAL (154)](https://mavlink.io/en/messages/common.html#MAV_COMP_ID_GIMBAL) | ||
|
|
||
| Gimbal movement is not immediate. | ||
| To ensure that the gimbal has time to move into position before the mission progresses to the next item (if gimbal feedback is not provided or lost), you should set [MIS_COMMAND_TOUT](../advanced_config/parameter_reference.md#MIS_COMMAND_TOUT) to be greater than the time taken for the gimbal to traverse its full range. | ||
| After this timeout the mission will proceed to the next item. |
There was a problem hiding this comment.
@julianoes Is this accurate? Specifically, my assumption is that all gimbal commands are sent to MAV_COMP_ID_GIMBAL but I couldn't find where.
There was a problem hiding this comment.
I had no idea this param existed.
I would be surprised if this worked at all. Something to check...
In terms of timeout: Usually the gimbals just answer with Ack, and then go to the setpoint, however slow they want. This behavior makes sense when used as a command - where you might want to send a new setpoint while it's still moving - but less as part of a mission, unfortunately. It might requiring adding in a wait command explicitly after.
In my mind, if a command is not answered immediately, it should be followed up by a IN_PROGRESS to avoid a timeout, as per protocol.
There was a problem hiding this comment.
Its a new param added in PX4/PX4-Autopilot#23960
Essentially it copies what was done for payload delivery - if you have feedback then the mission item completes on getting that, but if you don't then it completes after a timeout - ensuring the gimbal has time to reach your target setpoint, or your gripper has time to open/closed.
This is what is done, and will work. Is it the right thing? Depends on whether the gimbal protocol provides feedback on reaching the target as you suggest or just acknowledges the command. We don't define the camera commands as long running, so I suspect the former is what happens. Is there any other way to get feedback?
In any case, can you confirm that commands are sent to MAV_COMP_ID_GIMBAL ?
There was a problem hiding this comment.
I will have to test this. On my list now. Being able to set the timeout can be good of course.
There was a problem hiding this comment.
@julianoes The timeout stuff is accurate and I don't want to wait on your testing to get this PR in. So what I have done is removed the text about addressing and recreated the problematic part in #3514
| ## Mission Command Timeouts | ||
|
|
||
| Some mission commands/items can take time to complete, such as a gripper opening and closing, a winch extending or retracting, or a gimbal moving to point at a region of interest. | ||
|
|
||
| Where provided PX4 may use sensor feedback from the hardware to determine when the action has completed and then move to the next mission item. | ||
| If not provided, or if the feedback is lost, a mission command timeout can be used to ensure that these kinds of actions will progress to the next mission item rather than blocking progression. | ||
|
|
||
| The timeout is set using the [MIS_COMMAND_TOUT](../advanced_config/parameter_reference.md#MIS_COMMAND_TOUT) parameter. | ||
| This should be set to be a small amount greater than the time required for the longest long-running action in the mission to complete. |
There was a problem hiding this comment.
Note, added this to all the vehicle mission mode sections.
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/params-since-v1-15-20241204/42717/1 |
hamishwillee
force-pushed
the
mission_command_timeout
branch
from
ac88068 to
4d4a05a
Compare
|
No flaws found |
Some hardware can take time to reach the state commanded by a corresponding mission item, such as gimbals, grippers, winches.
Ideally you'd trigger transition to the next step on feedback from a sensor on the hardware, but many grippers etc don't have that, and in any case it is possible you will miss it. So for grippers the
MIS_PD_TOtimeout was created - it basically ensures that if you miss feedback (or if there is none) the mission will wait this amount of time before progressing.PX4/PX4-Autopilot#23960 renames
MIS_PD_TOwithMIS_COMMAND_TOUT, which applies to all of these long running mission items - it also uses this delay to give the gimbal time to move into position on a mission item.This provides the corresponding docs.